2024.08.20 Scrum Developers Night Online
1st Discussion ~21:00
生産性の指標ってどうやってますか？
4keys
どう使っている？
どういうツール使っている？
形骸化しちゃうよね
テクニカルな部分もいいけど、もっと人間的な数値を見てみるのもよいかも？
残業時間と満足度
eNPS
ニコニコカレンダー、幸福度
最近、運用作業に追われて開発に割く時間が減ってきています 皆様のチームではどのようにバランスをとられていますか？
今のチームで開発者が減ってきてしまっているという不安が強い、というのを認識
やれることはいつでもやりたいことより少ない、その中でどうやるか
優先順位をしっかりつけて着手していく
優先順位をつけるにあたっての透明性の確保
「運用作業」には実際どれくらい時間がかかっているのかを可視化する
問題の発見
問題意識を揃える
toCが故に締め切りがないタスクが多いのですが、よく見るスクラムの記事などでは締め切りがあることが多いのでtoC x スクラムの経験がある方は上手くハマった教えていただきたいです！
今のチームではPOが役割を果たせていないのでは？
チームメンバーが支えて動くことはできていることには気づけた、プラスアルファの改善をレトロスペクティブで話せるといい
受け入れ基準と完成の定義の言葉を使い分ける
toCでも事業規模などで求めることが違うはず。スタートアップであれば、売り上げを伸ばすこと？
2nd Discussion ~21:30
効果的だった振り返りをどうやったか聞かせてください
いいtryが出せない、そのtryを実行できない
tryに対してふりかえりやってない？
小さなtryを積み重ねて成功体験をすればメンバーもついてくる？
PBIとしてtryを位置付ける、POが納得してくれるようなtryを考える
フレームワーク
KPT
KPT以外
keepだけを考えるふりかえり
Sailboat
1チームで複数プロジェクトでもスクラムはできますか？
スクラムはできる！となった
プロジェクトや会社によって形がいろいろ違うというのがわかった
自分たちの状況を説明しているなかで、自分たちの状況・やり方が複雑になってしまっていることに気づいた
単純なやり方で解決することもできそう
自分たちがどうやっているのかを全体的に振り返る機会があるとよさそう！
3rd Discussion ~22:05
見積もりについて 相対見積もりと時間見積もりどちらで進めたらいいか迷っています
もともと、時間見積もりでやっていた
しかし、今日と、1年後でやるときとでスキルアップしているから時間が変わってしまうはず、そこで相対見積もり
相対見積もり、時間がかかる？
新卒の人とか自分の得意分野以外でも、3週間くらい一緒にやっていると精度高く見積もれるようになっていく
見積もった後に分解するというのも大事
開発タスク以外についても相対見積もりが有効
細かくして見積もっていく
わかっていることをベースに見直すというのが大事
チームが求めていること、いないことのリサーチにかける時間 vs フレームワークに則った改善をしたい気持ち
自分の知っている、使ったことのあるプラクティスの根拠や背景も一緒にメンバーに伝える必要がある
ふりかえりで自分の経験値バトルで押すのを辞めようと思う
ソリューションがどんな課題に対して向けられていて、どうしてそれが有効なのかを検証できているのか？
意思決定プロセスがないのでは？どういう根拠で特定の決定をするのか？
どの課題に取り組むのかを考える/どのソリューションをとるのかを考える
発散・収束
収束でドット投票を使うのは根拠がない、ROIやアイゼンハワーマトリクスを使う
全体的な設計（DBとかの、後から考えると破綻しそうなやつ）ってどうやってますか？
先に業務の要件などを洗い出しておいて考えるというのは他の人も先にやっているというお話
PBIとして仮説の検証（ヒアリングしてドキュメントにする）を扱うとか
みんなでレビューできるようなものを成果物として位置付ける
スクラムのプロセスに入る前にやってしまうこともある
Enough Design Upfrontのための基準
「明日の天気予報」くらい＝「まぁ当たるよね」というもの
フィードバック